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REAL PARTY IN INTEREST 
The real party in interest is Hewlett-Packard Development Company, L.P. of Hous- 
ton, Texas. 

RELATED APPEALS AND INTERFERENCES 
Applicant and their legal representatives know of no related appeals or interferences 
that will directly affect or be directly affected by or have a bearing on the Board's decision in 
the present appeal. 

STATUS OF CLAIMS 
Claims 1-40 are pending in the case. Claims 1-40 stand finally rejected under 35 
U.S.C. §103. 

A copy of claims 1-40, in their current form, is attached hereto as an Appendix. 

STATUS OF AMENDMENTS 
No amendments have been filed since the mailing of the Final Rejection on May 10, 

2005. 

SUMMARY OF CLAIMED SUBJECT MATTER 
The summary is set forth in eleven exemplary embodiments that correspond to inde- 
pendent claims 1, 6, 1 1, 14, 19, 20, 21, 27, 30, 33 and 36. Discussions about elements and 
recitations of these claims can be found at least at the cited locations in the specification and 
drawings. 

Independent claim 1 is directed to a computerized file system in which a first process 
(252), which may reside in a server node (202), maintains a data file (250). A second process 
(260), which may reside at a client node (204), generates a first message (300) that requests 
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that the second process be granted a plurality of tokens that are required to modify at least 
one characteristic of the data file. The first process (252) generates a second message (302) 
that grants the tokens to the second process, assuming they are available. Specification, p. 
13, line 1 to p. 15, line 4, and Figs. 3-5. 

Independent claim 6 is directed to a computer node (202) including a first process 
(252) residing in the node that generates a first message (302) that grants a set of tokens to a 
second process (260) that requested the grant of the set of tokens, where the set of tokens is 
required for the second process to modify at one characteristic of a file (250). Specification, 
p. 1 1, line 12 to p. 15, line 4, and Figs. 2-3. 

Independent claim 1 1 is directed to a computer node (204) including a first process 
(260) that generates a request to a second process (252) for a set of tokens required to modify 
at least one characteristic of a file (250). Specification, p. 13, line 1 to p. 15, line 4, and Figs. 
3-5. 

Independent claim 14 is directed to a network computing system comprising a first 
node (202) having a data file (250), and a second computer node (204) that issues a first mes- 
sage (300) requesting the grant of a set of tokens for modifying at least one characteristic of 
the data file, where the first computer node issues a second message (302) to the second com- 
puter node that grants the set of tokens if they are available. Specification, p. 1 1, line 12 to p. 
12, line 11, p. 13, line 1 to p. 15, line 4, and Figs. 2-5. 

Independent claim 19 is directed to a computer-readable memory (210) containing 
computer-executable program instructions including a first instruction that maintains a data 
file (250) in computer storage memory, a second instruction that generates a first message 
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(300) requesting the grant of a plurality of tokens that are required to modify at least one 
characteristic of the data file, and a third instruction that generates a second message (302) 
that grants the tokens, assuming they are available. Specification, p. 1 1, line 12 to p. 15, line 
4, and Figs. 2-5. 

Independent claim 20 is directed to a computer-readable memory (210) containing 
computer-executable program instructions including first instructions that generate a first 
message (302) granting a set of tokens to a requester (260) of the set of tokens, where the set 
of tokens is required to modify at least one characteristic of a file (250). Specification, p. 1 1, 
line 12 to p. 15, line 4, and Figs. 2-5. 

Independent claim 21 is directed to a computer-readable memory (210) containing 
computer-executable program instructions including first instructions that generate a request 
(300) for a grant of a set of tokens required to modify by an issuer (260) of the request at 
least one characteristic of a file (250). Specification, p. 1 1, line 12 to p. 15, line 4, and Figs. 
2-5. 

Independent claim 27 is directed to a computerized file system including means for 
maintaining a data file (processor 212, memory 210, and data file 250 of node 202), means 
for generating a first message (processor 212 and memory 210 of node 204, and message 
300) requesting a grant of a plurality of tokens for modifying at least one characteristic of the 
file, and means for generating a second message (processor 212 and memory 210 of node 
202, and message 302). In response to the first, that grants the tokens if they are available. 
Specification, p. 1 1, line 14 to p. 15, line 4, and Figs. 2-5. 
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Independent claim 30 is directed to a computerized method including maintaining a 
data file (250), generating a first message (300) requesting a grant of a plurality of tokens to 
modify at least one characteristic of the file, and generating a second message (302) in re- 
sponse to the first, that grants the tokens if they are available. Specification, p. 1 1, line 14 to 
p. 15, line 4, and Figs. 2-5. 

Independent claim 33 is directed to a computerized method including generating a 
first message (302) that grants a set of tokens that are required to modify at least one charac- 
teristic of a file (250). Specification, p. 1 1, line 14 to p. 15, line 4, and Figs. 2-5. 

Independent claim 36 is directed to a computerized method including generating a re- 
quest (300) for a grant of a set of tokens required to modify at least one characteristic of a file 
(250). Specification, p. 1 1, line 14 to p. 15, line 4, and Figs. 2-5. 

GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Whether claims 1, 6, 1 1, 14, 19, 20, 21,21, 27, 30, 33 and 36, which otherwise meet 
all conditions of patentability under Title 35 of the United States Code, are unpatentable un- 
der 35 U.S.C. §103 over U.S. Patent No. 5,634,122 issued to Loucks et al. (hereafter 
"Loucks") in view of U.S. Patent No. 5,506,961 to Carlson et al. ("Carlson"), where the art 
of record either alone or in combination fails to teach or suggest, among other things, a single 
message that carries a plurality of tokens that are required to modify a characteristic of a file. 

ARGUMENT 

Legal Standard 

In rejecting claims under 35 U.S.C. §103, the examiner bears the initial burden of 
presenting a prima facie case of obviousness. See , e.g. . In re Riickaeit 9 F.3d 1531, 1532 
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(Fed. Cir. 1993). To establish a prima facie case of obviousness, the references, when con- 
sidered in their entirety, must teach or suggest all of the claimed limitations. If the references 
fail to teach or suggest any one of the claimed limitations, then the rejection should be re- 
versed. An examiner may not, moreover, resort to speculation, unfounded assumption or 
hindsight reconstruction to supply deficiencies in the references. In re Warner , 379 F.2d 
1011, 1017 (CCPA 1967). 

The claims do not stand or fall together. Instead Applicant presents separate argu- 
ments for various independent and dependent claims. Each of these arguments is separately 
argued below and presented with separate headings and sub-headings as required by 37 
C.F.F. §41.37(c)(l)(vii). 

Claims L 14, 19, 27 and 30 

Claim 1 recites as follows: 

"A computerized data file system, comprising:" 

"a first process that maintains a data file stored in a computer-readable mem- 
ory", and 

"a second process that generates a first message requesting that said second 
process be granted by said first process a plurality of tokens required for said second 
process to modify at least one characteristic of said file stored in said computer- 
readable memory", 

"said first process generating a second message, in response to said first mes- 
sage, that grants said tokens to said second process if said tokens are available for 
grant to said second process". 

As shown, claim 1 recites, among other things, that there are a plurality of tokens being re- 
quested by the second process in the single first message, and that there are a plurality of 
tokens being granted by the first process in the single second message. 
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With regard to the second limitation of claim 1 , the final Office Action relies on 
Loucks as purportedly teaching "a second process that generates a first message requesting 
that said second process be granted", and on Carlson as purportedly teaching "a plurality of 
tokens required for said second process to modify at least one characteristic of said file stored 
in said computer readable memory". The final Office Action further contends that Loucks 
teaches claim 1 's third element, i.e., the "first process generating a second message, in re- 
sponse to the first message, that grants the tokens to the second process if the tokens are 
available for grant to the second process". As set forth herein, Applicant respectfully dis- 
agrees that Loucks or Carlson either alone or in combination teaches or suggests a single 
message that either requests or grants a plurality of tokens required to modify a file. 

Description of the Cited References 

Loucks describes a technique for controlling access to shared resources in a distrib- 
uted computer system using a token manager. See Abstract. In order to access the shared 
resource, a process (e.g., a client process) must hold a single token associated with the opera- 
tion. The token represents an authorization for the client process to perform the operation. 
See Abstract, and Col. 6, lines 8-18. If the client process does not hold the token, it requests 
the token from a token manager. See Col. 6, lines 12-16. The token manager examines a list 
of tokens it holds and, depending on the content of the list, may request a new token from a 
local token manager. Alternatively, it may request that another client process revoke a token, 
or it may simply grant an available token to the requesting client process. See Col. 6, lines 
28-36. 
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When a token is requested from the local token manager, the local token manager de- 
termines if the requested token conflicts with other outstanding tokens. See Col. 7, lines 2-7. 
If no conflict exists, the local token manager grants the token. Otherwise, if a conflict exists 
(e.g., the token is granted to another process), the local token manager first revokes the token 
from the process holding the token, and then grants the token to the requesting client process. 
See Col. 7, lines 6-12. Specific token requests may cause the revocation of multiple tokens. 
For example, a request for an exclusive write token on a file causes the token manager to re- 
voke all granted read tokens on that file before granting the exclusive write token to the re- 
questing process. See Col. 7, lines 9-12. 

In summary, with Loucks a process requests a single token from a token manager in 
order to access a shared resource. The token manager, in turn, either grants the token imme- 
diately, requests the token from a local token manager, or revokes the token from another 
process. Moreover if the requested token is not available, depending on the type of the token 
requested, the token manager may, in turn, revoke several other types of tokens from other 
processes before granting the requested single token . 

Carlson is directed to a peer-to-peer connection authorizer that prevents unauthorized 
access to a computer system's resources. See Summary of the Invention. With Carlson, 
when a client device requests access to a server of the computer system, a system authorizer 
(112) first verifies that the client is a legitimate user of the computer system. If so, the sys- 
tem authorizer issues copies of the same token to both the client and the server. In its request 
to the server, the client includes a copy of the received token. Col. 6, lines 37-42. The server 
compares the token contained in the request from the client with the token that the server re- 
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ceived from the system authorizes Col. 6, lines 43-45. If they are the same, then the server 
responds to the client. Col. 6, lines 45-50, and Col. 11, lines 16-44. 

If the request by the client involves multiple servers, then the system authorizer sends 
each of the servers a copy of the token. Col. 4, lines 9-10, and Col. 8, lines 15-18. 

Carlson also describes three different token types that may be issued by the system 
authorizer: a single-use token, a reusable token and a generic token. Col. 8, lines 15-65. A 
single use token is used once and then destroyed. Col. 8, lines 16-17. A reusable token is 
issued when the system authorizer determines that continued access to information is re- 
quired. Col. 8, lines 40-43. A generic token permits free access to information on a particu- 
lar server device. Col. 8, lines 63-65. 

As mentioned above, in rejecting claim 1, the final Office Action contends that Carl- 
son teaches a plurality of tokens requested by a client in order to modify a file. Applicant 
submits Carlson fails to support such a teaching. 

In particular, Col. 4, lines 5-10 of Carlson, which is one of the excerpts relied on by 

the final Office Action, states as follows: 

Depending on security needs, the token may or may not be encrypted. It is also pos- 
sible that the requisite information resides on more than one server device or that 
more than one client device requires the information. The system authorizer handles 
multiple device situations by dispatching multiple tokens and token copies. 

(emphasis added) Applicant submits that this excerpt teaches a system in which each client 

device requests only one, single token. This is confirmed by Carlson's use of the terms "a 

token" and "the token" in the above excerpt. Applicant further submits that the reference to 

multiple tokens by Carlson has to do, not with a single client requesting multiple tokens in a 
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single message, but with the situation where there are multiple servers. According to Carl- 
son, if there are multiple servers, then multiple tokens will be dispatched; one to each server . 

The other parts of Carlson cited by the final Office Action likewise fail to teach or 
suggest a client request for multiple tokens to modify a file. For example, at Col. 8, lines 6- 
10, Carlson states that: 

System authorizer mechanism 1 12 will receive this request in functional block 
810. Based on the nature of the request and general system factors, system authorizer 
mechanism 112 will determine the type of token, the number of tokens sent out, and 
the distribution of token types 815. 

And, at Col. 9 lines 2-5 and 16-25, Carlson states that: 

Once again, system authorizer mechanism 112 could determine that these conditions 

exist for more than just optical storage devices 340 and send out multiple tokens. 

* * * 

Once the requested information has been located and the token or tokens of a 
particular type have been created (and possibly encrypted), system authorizer mecha- 
nism 1 12 bundles it/them into a PTPA message and sends the message(s) to the sub- 
ject server connection manager(s). FIG. 4 shows the format of the PTPA message in 
more detail. Field 430 contains the PTPA message type indicator. Field 435 is used 
within the IPCF protocol to identify the entity for which the authorization is intended. 

Applicant agrees that Carlson discusses multiple tokens. However, what these excerpts teach 
is that, when a client request is to be serviced by multiple servers, Carlson's system author- 
izer sends to each such server a separate copy of the same token that is also being provided to 
the client. 

In other words, Carlson's reference to multiple tokens has to do, not with a single cli- 
ent requesting multiple tokens, but with the issuance of multiple copies of the same token to 
different servers needed to satisfy a client request. At most, Carlson's client requests and 
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receives a single token, which it then forwards to the server as part of its request for informa- 
tion. This is made clear at Col. 4, lines 1-10 where Carlson states as follows: 

If the system authorizer determines that the client device should be allowed to access 
the information on the subject server device, it then sends a token to the server device 
and a copy of the same token to the client device. Depending on security needs, the 
token may or may not be encrypted. It is also possible that the requisite information 
resides on more than one server device or that more than one client device requires 
the information. The system authorizer handles multiple device situations by dis- 
patching multiple tokens and token copies. 

(emphasis added) 

Based on the foregoing, Applicant submits that Carlson fails to teach or suggest "a 
second process" that generates a "first message" requesting a "plurality of tokens" so that the 
second process may modify at least one characteristic of a file, as contended in the final Of- 
fice Action's rejection of claim 1 . 

Applicant also submits that Loucks fails to teach or suggest the third limitation of 
claim 1, namely, a second message, which is in response to a first message, and that grants a 
plurality of tokens required to modify a file. The final Office Action cites to Col. 9, lines 18- 
30 and 40-48, and Col. 11, lines 18-32 of Loucks as purportedly teaching the third limitation 
recited in claim 1 . Applicant respectfully disagree that the cited portions of Loucks provide 
such a teaching. 

The cited excerpts from Col. 9 of Loucks state as follows: 

In addition to the Open tokens 702 and Lock tokens 704, the present invention intro- 
duces two new token types to support the above clients: Stash token 706 and Re- 
integration token 708. 

The Stash token is acquired for an entire fileset or for individual files. The 
stash token is a read-only shared token. It is requested by an MDFS client cache 
manager (MCM) to indicate this client's intention to disconnect from the server. The 
client MCM requests the Stash token from the Mobile Protocol Exporter MPX [See 
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FIG. 5] for an entire fileset. MCM does not need to request stash tokens for the indi- 
vidual files in the fileset. MPX requests the Stash token on the fileset from the local 
token manager Itkm. 

* * * 

Since requesting a Stash token indicates that the client is getting ready to dis- 
connect and is probably in desperate need for files in that fileset, an option "as is" is 
defined to allow the client to get the files. The client can request the Stash token with 
the "as is" option. If an Open_Exclusive token for the fileset is being held by another 
client or by a local process on the server, it usually means that there is some repair 
operation on the fileset. The requesting client will get the stash token with a return 
code that indicates the fileset structure may be changing. Thus, a request for a Stash 
token with the "as is" option is always granted. 

The cited excerpt from Col. 1 1 of Loucks states as follows: 

If mtkr has not previously acquired the requested token (N output of 906), it 
sends an Open_Write token request to the MDFS server token manager mtkm (922) 
and waits for reply (924). If the reply was to grant the token (Y output of 926), the 
mtkr proceeds to grant the token (916) as described above. If the reply from mtkm 
was to deny the token request or if time-out was reached before a reply is received (N 
output of 926), then mtkr proceeds to deny the token request (91 8) as described 
above. In both cases, this ends the processing of the current token request operation 
at mtkr. 

FIG. 9b represents the steps executed by the mtkm. They are similar to those 
explained in description of FIG. 8, with the "OpenWrite token" request for fileset y 
replaced by "Open_Write token" request for file f. 

Applicant agrees that Loucks describes multiple types of tokens. See, e.g. . Col. 6, 
lines 9-12. However, the issue is whether Loucks teaches or suggests a process that gener- 
ates a single message granting a plurality of tokens required to modify a file. Applicant re- 
spectfully submits that Loucks fails to provide such a teaching. 

First, the above excerpts of Loucks do not teach or suggest the granting of a plurality 
of tokens with a single message. Instead, the above excerpts from Col. 9 teach the use of a 
different type of token depending on the particular circumstances, including a Stash token 
that can be used to obtain a fileset even though the fileset may be undergoing a change. The 



12 



PATENTS 
15311-2207 
200308268-1 



above excerpt from Col. 1 1 teaches a request for a single token (the Open_Write token), 
which either results in the single OpenWrite token being granted or in the request being de- 
nied. In sum, the cited excerpts fail to teach or suggest a process that generates a single mes- 
sage granting a plurality of tokens for modifying a file. 

A review of other portions of Loucks further demonstrates that a grant is only made 
of a single token, not a plurality of tokens as recited in claim 1 . At Col. 6, lines 28-34, for 
example, Loucks states as follows: 

When a token requester, mtkr 418, of an MDFS client requests a token from 
the token manager 420, the token manager examines the list of tokens it holds on be- 
half of all its clients. Depending on the contents of this list, it may request a new to- 
ken from the local token manager, request "revoke token" from one or more clients, 
or simply grant an available token to the requesting client. 

(emphasis added). 

At Col. 10, lines 24-27, Loucks states: 

If an Open_Exclusive token has been previously granted to mtkm (Y output for 824), 
or if no such token has been previously granted (N output for 822), the ltkm grants 
the requested token (826). 

(emphasis added). 

At lines 27-39 of Col. 10, Loucks states: 

When a reply is received that indicates the token is relinquished by its current holder 
(N out of 844), ltkm proceeds to grant the token (826). 

(emphasis added). 

Finally, at Col. 11, lines 13-18, Loucks states: 

If there is no conflict (N output of 908), or if the process holding the conflicting token 
ends its file system call (Y output of 912), then mtkr proceeds to grant the requested 
token (916). Granting a token involves updates to mtkr data structures and sending 
a "grant token request" to the requesting process. 
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(emphasis added). 

All of the above excerpts demonstrate that Loucks teaches the grant of a single token. 
There is no teaching or suggestion by Loucks for a single message that somehow grants a 
plurality of tokens. Because Loucks fails to teach or suggest a single message for granting a 
plurality of tokens, the rejection of claim 1 should be reversed. 

Independent claims 14, 19, 27 and 30 likewise recite a first message that requests "a 
set" or "a plurality" of tokens, and a second message granting "the set" or "the plurality" of 
tokens. As set forth above, neither Loucks nor Carlson either alone or in combination teach 
or suggest such messages. Accordingly, the rejection of claims 14, 19, 27 and 30 should also 
be reversed. 

Claims 6, 20 and 33 

Independent claim 6 recites in relevant part: 

"a first message that grants a set of tokens ... the set of tokens being required for the 
second process to be able to modify at least one characteristic of a file". 

As set forth above, neither Loucks nor Carlson teaches or suggests a single message that 
grants a plurality of tokens. 

This is made clear by reference to the format of Carlson's authorization message 465, 
which is shown at Fig. 4. As shown, the message 465 only has room to grant a single token, 
namely the Server token 440. This condition is confirmed by Carlson in his written descrip- 
tion at Col. 9, lines 27-28 where he states "Field 440 contains the actual token itself (em- 
phasis added). Thus, by definition, Carlson's authorization message 465 can grant but one 
token. 
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Independent claims 20 and 33 likewise recite "a first message that grants a set of to- 
kens". Therefore, the rejection of these claims should be reversed. 
Claims 11, 21 and 36 

Independent claim 1 1 recites in relevant part: 

"a first process . . . that generates a request to a second process for a grant of a set of 
tokens required to enable the first process to modify at least one characteristic of a 
file". 

As set forth above in the analysis regarding claim 1, neither Loucks nor Carlson teach 
or suggest a request for a set, e.g., multiple, tokens. Accordingly, the rejection of claim 1 1 
should be reversed. 

Independent claims 21 and 36 similarly recite "a request for grant of a set of tokens". 
Thus, the rejection of these claims should also be reversed. 

In sum, Applicant submits that the final Office Action fails to establish a prima facie 
case of obviousness, and that therefore the rejection of claim 1-40 should be reversed. 
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CONCLUSION 



Applicant respectfully submits that the claims are allowable over the art of record. 
Accordingly, Applicant request that the rejection of all claims be reversed. 



Please direct all correspondence to: 

IP Administration Legal Department, 
M/S35 

Hewlett-Packard Co. 

P.O. Box 272400 

Fort Collins, CO 80527-2400 



Respectfully submitted, 




Michael R. Reinemann 



Reg. No. 38,280 
Tel. 617-951-3060 
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CLAIMS APPENDIX 
(Claims on Appeal in Appl. Ser. No. 09/428,384) 



1 1 . (Previously presented) A computerized data file system, comprising: 

2 a first process that maintains a data file stored in a computer-readable memory; and 

3 a second process that generates a first message requesting that said second process be 

4 granted by said first process a plurality of tokens required for said second process to modify 

5 at least one characteristic of said file stored in said computer-readable memory; 

6 said first process generating a second message, in response to said first message, that 

7 grants said tokens to said second process if said tokens are available for grant to said second 

8 process. 

1 2. (Original) A system according to claim 1, wherein: 

2 said first process is resident at a server computer node, and said second process is 

3 resident at a client computer node. 

1 3. (Original) A system according to claim 1 , wherein: 

2 if any of said tokens are unavailable for grant to said second process as a result of 

3 current grant of said tokens to at least one other process, said first process generates a third 

4 message revoking the current grant of said tokens to said at least one other process. 

1 4. (Original) A system according to claim 3, wherein: 

2 said at least one other process, in response to said third message, generates a fourth 

3 message making said tokens available for grant by said first process. 

1 5. (Original) A system according to claim 3, wherein: 

2 said first process resides in a first computer node; 

3 said second process resides in a second computer node; 

4 said at least one other process resides in at least one other computer node; and 
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5 said first computer, second computer, and at least one other computer nodes are net- 

6 worked together and are remote from each other. 

1 6. (Previously presented) A computer node, comprising: 

2 a first process residing in said node that generates a first message that grants a set of 

3 tokens, if the set of tokens is available for grant, to a second process that requested grant of 

4 the set of tokens, the set of tokens being required for the second process to be able to modify 

5 at least one characteristic of a file stored in a computer-readable memory within the computer 

6 node. 

1 7. (Previously presented) A node according to claim 6, wherein: 

2 the second process resides in a remote computer node. 

1 8. (Previously presented) A node according to claim 7, wherein: 

2 one of the first and second processes resides in a server computer node and the other 

3 of the processes resides in a client computer node. 

1 9. (Original) A node according to claim 6, wherein: 

2 if at least one token in the set of tokens is unavailable for grant because the at least 

3 one token is currently granted to a third process, the first process also generates a second 

4 message that revokes current grant of the at least one token to the third process prior to gen- 

5 erating the first message. 

1 10. (Original) A node according to claim 6, wherein: 

2 the first message is generated by the first process in response to a request for the grant 

3 of the set of tokens generated by the second process, the request specifying all tokens re- 

4 quired for the second process to be able to modify the at least one characteristic of the file. 

1 11. (Previously presented) A computer node, comprising: 
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2 a first process residing in said node that generates a request to a second process for 

3 grant of a set of tokens required to enable the first process to modify at least one characteris- 

4 tic of a file residing in a remote computer-readable memory. 

1 12. (Original) A node according to claim 11, wherein: 

2 the second process resides in a second computer node, and the memory is comprised 

3 in said second node. 

1 13. (Original) A node according to claim 11, wherein: 

2 the set of tokens comprises all tokens required for the first process to be able to mod- 

3 ify the at least one characteristic of the file. 

1 14. (Previously presented) A network computer system, comprising: 

2 a first computer node having a data file stored in a computer-readable memory; and 

3 a second computer node that issues to the first computer node a first message request- 

4 ing grant of a set of tokens required to carry out a modification of at least one characteristic 

5 of said file stored in the first computer node; 

6 the first computer node issuing a second message to the second computer node after 

7 receipt of the first message, the second message granting the set of tokens to the first process 

8 if the set of tokens is available for grant to the second process. 

1 15. (Previously presented) A system according to claim 14, wherein: 

2 the first computer node is a server node, and the second computer node is a non- 

3 server node. 

1 16. (Previously presented) A system according to claim 14, wherein: 

2 the set of tokens comprises all tokens required to carry out the modification of the at 

3 least one characteristic of the file. 
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1 17. (Previously presented) A system according to claim 14, wherein: 

2 if at least one token in the set of tokens is unavailable for the grant because the at 

3 least one token is currently granted, the first computer node waits to issue the first message 

4 until after the first computer node receives a third message from a third computer node indi- 

5 eating relinquishment of current grant of the at least one token. 

1 18. (Previously presented) A system according to claim 17, wherein: 

2 the at least one token comprises a plurality of tokens. 

1 19. (Previously presented) Computer-readable memory containing computer-executable pro- 

2 gram instructions, the instructions comprising: 

3 first instructions which when executed permit a data file to be maintained in a com- 

4 puter storage memory; 

5 second instructions which when executed generate a first message requesting grant of 

6 a plurality of tokens required to modify at least one characteristic of said file located in said 

7 computer storage memory; and 

8 third instructions which when executed generate a second message, in response to 

9 said first message, that grants said tokens if said tokens are available for grant to said second 
10 process. 

1 20. (Previously presented) Computer-readable memory containing computer-executable pro- 

2 gram instructions, the instructions comprising: 

3 first instructions which when executed generate a first message that grants a set of 

4 tokens, if the set of tokens is available for grant, to a requester of the set of tokens, the set of 

5 tokens being required to permit the requester to be able to modify at least one characteristic 

6 of a file stored in computer storage memory. 

1 21. (Previously presented) Computer-readable memory containing computer-executable pro- 

2 gram instructions, the instructions comprising: 
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3 first instructions that when executed generate a request for grant of a set of tokens 

4 required to enable modification by an issuer of the request of at least one characteristic of a 

5 file residing in storage memory. 

1 22. (Previously presented) Computer-readable memory according to Claim 19, further com- 

2 prising: 

3 further instructions which when executed causes, if any of said tokens are unavailable 

4 for grant as a result of current grant of said tokens, generation of a third message revoking 

5 the current grant of said tokens. 

1 23. (Previously presented) A computer-readable memory according to claim 22, wherein: 

2 said further instructions, in response to said third message, generate a fourth message 

3 making said tokens available for grant. 

1 24. (Previously presented) Computer-readable memory according to claim 20, further com- 

2 prising: 

3 further instructions which when executed cause, if at least one token in the set of to- 

4 kens is unavailable for grant because the at least one token is currently granted, generation of 

5 a second message that revokes previous grant of the at least one token prior to generating the 

6 first message. 

1 25. (Previously presented) Computer-readable memory according to claim 20, wherein: 

2 the first message is generated in response to a request for the grant of the set of tokens 

3 generated, the request specifying all tokens required to be able to modify the at least one 

4 characteristic of the file. 

1 26. (Previously presented) Computer-readable memory according to claim 21, wherein: 

2 the set of tokens comprises all tokens required to be able to modify the at least one 

3 characteristic of the file. 
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1 27. (Previously presented) A computerized data file system, comprising: 

2 means for maintaining a data file stored in a computer-readable memory; and 

3 means for generating a first message requesting grant of a plurality of tokens required 

4 to modify at least one characteristic of said file stored in said computer-readable memory; 

5 means for generating a second message, in response to said first message, that grants 

6 said tokens if said tokens are available for grant. 

1 28. (Previously presented) A system according to claim 27, further comprising: 

2 means for generating, if any of said tokens are unavailable for grant as a result of cur- 

3 rent grant of said tokens, a third message revoking the current grant of said tokens. 

1 29. (Previously presented) A system according to claim 28, further comprising: 

2 means for generating, in response to said third message, a fourth message making 

3 said tokens available for grant. 

1 30. (Previously presented) A computerized method for coherently maintaining and modifying 

2 a data file, comprising: 

3 maintaining the data file in a computer-readable memory; 

4 generating a first message requesting grant of a plurality of tokens required to modify 

5 at least one characteristic of said file in said computer-readable memory; and 

6 generating a second message, in response to said first message, that grants said tokens 

7 if said tokens are available for grant. 

1 31. (Previously presented) A method according to claim 30, further comprising: 

2 if any of said tokens are unavailable for grant as a result of current grant of said to- 

3 kens to at least one other process, generating a third message revoking the grant of said to- 

4 kens. 

1 32. (Previously presented) A method according to claim 3 1 , wherein: 

22 



PATENTS 
15311-2207 
200308268-1 



2 in response to said third message, a fourth message making said tokens available for 

3 grant is generated. 

1 33. (Previously presented) A computerized method for use in maintaining coherency of a 

2 data file stored in a computer-readable memory, comprising: 

3 generating a first message that grants a set of tokens, if the set of tokens is available 

4 for grant, to a requester of the grant of the set of tokens, the set of tokens being required for 

5 requester to be able to modify at least one characteristic of the file stored in the computer- 

6 readable memory. 

1 34. (Previously presented) A method according to claim 33, wherein: 

2 if at least one token in the set of tokens is unavailable for grant because the at least 

3 one token has been currently granted, the method also comprises a second message that re- 

4 vokes current grant of the at least one token prior to generating the first message. 

1 35. (Previously presented) A method according to claim 33, wherein: 

2 the first message is generated in response to a request for the grant of the set of tokens 

3 generated by the requester, the request specifying all tokens required for the requester to be 

4 able to modify the at least one characteristic of the file. 

1 36. (Previously presented) A computerized method for use in maintaining coherency of a 

2 data file stored in a computer-readable memory, comprising: 

3 generating a request for grant of a set of tokens required to enable modification of at 

4 least one characteristic of the file stored in the computer-readable memory. 

1 37. (Previously presented) A method according to claim 36, wherein: 

2 the set of tokens comprises all tokens required to be able to modify the at least one 

3 characteristic of the file. 
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1 38. (Previously presented) The system according to claim 1 , wherein: 

2 said second process, in response to receiving said second message, modifies said at 

3 least one characteristic of said file stored in said computer-readable memory. 

1 39. (Previously presented) The system according to claim 27, further comprising: 

2 means for modifying said at least one characteristic of said file stored in said com- 

3 puter-readable memory. 

1 40. (Previously presented) The method according to claim 30, further comprising: 

2 modifying said at least one characteristic of said file in said computer-readable mem- 

3 ory. 
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EVIDENCE APPENDIX 



25 



